home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Almathera Ten Pack 2: CDPD 1
/
Almathera Ten on Ten - Disc 2: CDPD 1.iso
/
pd
/
101-125
/
118
/
wiredemo
/
tech.doc
< prev
next >
Wrap
Text File
|
1995-03-13
|
4KB
|
97 lines
To: bryce@hoser.berkeley.edu
Subject: Re: Here's a Demo
Precedence: special-delivery
Unless you have a better ball that is the final version (as far
as the contest goes). Here is a tech description. Source is also
available, of course. (I guess I'll bring the source to the BADGE meeting
on the 15th).... I'm not sure if Tom wants a tech description on how the
demo was created, but if he does you can send him the one below. Otherwise
it is for your curiosity and reading pleasure.
--------------------------------------------------------------------------
TECHNICAL DESCRIPTION OF WIREDEMO FOLLOWS
--------------------------------------------------------------------------
DISPLAY
Camera: x,y,z of camera (coordinate range -16384 to 16383)
x,y,z of center (coordinate range -16384 to 16383)
Note that one degree of freedom is missing.... the rotational angle of the
vector. This means that if, say, you were looking exactly downward from
above you would have no control over the rotation of the view you were
seeing. As far as this demo goes, we do not care, and this cuts the point
calculation time in half.
The THETA and PHI between the vector (center,camera) and the x axis is
calculated just once per frame, as are various trig functions of THETA and
PHI. Angles are stored in the range 0x0000-0xFFFF (0 to twopi) and the
results of COS and SIN are in the range -16384 to 16384 (-1 to 1). This
version of the demo uses floating point calculations for COS/SIN/ATAN/RANGE
and then converts to integers. Future versions will simply use lookup tables.
For each point (All points are 16 bit integers. Calculations utilize 32 bit
intermediate quantities):
*Translate point by -CenterX,-CenterY,-CenterZ (camera center point),
as well as the object's X,Y,Z coordinate. This is effectively a
single subtraction per x,y,z. Note that translating an object
relative to the world takes no extra CPU and is absorbed in
translating it to the camera center.
*Rotate the point by -THETA(xy),-PHI(xz). The equations were
generated from a standard 3D rotation matrix. It takes 6 or 7
short (MULS) multiplications and as many additions. All trig
functions are precomputed (once per frame).
To multiply a point by a COS/SIN function result we do the equivalent
of a MULS, then shift the 32 bit result right by 15 to fix the
decimal point.
*X is now depth, Z vertical, and Y -horizonal in our camera
coordinate system. Swap coordinate elements around so Z is depth,
X and Y are horizonal and vertical components (no CPU time.. just
a matter of proper assignment). This is just so I don't get confused.
*Generate a false perspective by dividing X and Y by some function of Z
(two multiplications and two divisions total)
Once the points are calculated for an object each line segment must be drawn.
We can't preclip the points because multiple line segments might use them in
different directions:
-Clip the line segment on the left, right, top, bottom, and back
(Z < 0).... relatively trivial but takes almost as much time as
point calculation.
-Display in Screen's RastPort (since we do our own clipping).
ANIMATION
Animation is accomplished by (A) moving the ball relative to the
world, (B) moving the camera center, and (C) moving the camera
itself. The AMIGA object does not move.
The camera center, camera, and ball are given velocity and
acceleration components. The camera center attempts to track the
ball, and the camera attempts to track the camera center. The
three items are given different acceleration characteristics to
facilitate the DEMO.
The ball is effected by gravity but I cheat when it hits Z=0...
we give it a 'boost' upward so it bounces to different heights.
The X and Y velocities of the ball are constant.
DISPLAY
A two bitplane custom screen is used. Smooth animation is obtained
by double buffering via the color pallette... draw into one bit plane
while displaying the other, then turn on the second bitplane, clear
the first, and draw into the first, etc.... This is accomplished by
SetRGB4() ,RP->Mask = xx, SetAPen(), and SetRast(Rp,0) calls once per
frame.
-Matt